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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The present document provides the ETSI endorsement of the 3GPP TS 23.228 "IP Multimedia Subsystem; Stage 2, 
Release 7". 

The present document provides the necessary adaptions to the 3GPP IP Multimedia Core Network Subsystem (IMS), in 
order to support the Access Networks and terminals in the scope of the present NGN Release. The present document 
also includes certain elements from 3GPP Release 8 (TS 23.228 V8.2.0) 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] 3GPP TS 23.228: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 7)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 
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Endorsement notice 

The elements of 3GPP TS 23.228 [1] apply, with the following modifications. 

NOTE: Underlining and/or strike-out are used to highlight detailed modifications where necessary. 

Global modifications to 3GPP TS 23.228 

Throughout the text of TS 23.228 

3GPP TS 23.228 [1] was originally written specifically with mobile terminals in mind accessing the IMS using GPRS. 
Unless otherwise specified in the present document, requirements indicating mobile terminals should be taken as also 
being applicable to all terminals accessing the NGN. 

Additionally replace items in 3GPP TS 23.228 [1] as follows: 

• "HSS" with "UPSF". 

• "IM CN Subsystem" with "IMS Core". 

NOTE: Those changes are assumed globally for the present document. 

2 References 

Insert the following references at the end of clause 2: 

[57] IETF RFC 4769 (November 2006): "lANA Registration for an Enumservice Containing Public 

Switched Telephone Network (PSTN) Signaling Information". 

[96] IETF RFC 3022: "Traditional IP Network Address Translator (Traditional NAT)". 

[97] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control Subsystem (RACS)": 
Functional Architecture". 

[98] ETSI TS 183 017: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for 
session based policy set-up information exchange between the Application Function (AF) and the 
Service Policy Decision Function (SPDF); Protocol specification". 

[99] 3GPP TR 23.981 (Release 6): "3rd Generation Partnership Project; Technical Specification Group 

Services and System Aspects; Interworking aspects and migration scenarios for IPv4 based IMS 
Implementations (Release 6)". 

Replace the references in 3GPP TS 23.228 [1] as shown in the table below. 





References in 3GPP TS 23.228 [1] 


Replaced references 


1 


3GPP TS 23.002: "Network Architecture". 


ETSI ES 282 001 : "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); NGN Functional Architecture 
Release 1". (note 1) 


5 


GSM 03.64: "Digital cellular telecommunication system 
(Phase 2+); Overall Description of the General Packet Radio 
Service (GPRS) Radio Interface; Stage 2". 


(note 2) 


6 


GSM 01 .04: "Digital cellular telecommunications system 
(Phase 2+); Abbreviations and acronyms". 


(note 2) 


7 


3GPP TS 23.221 : "Architectural Requirements". 


(note 2) 


8 


3GPP TS 22.228: "Service requirements for the IP multimedia 
core network subsystem". 


ETSI TR 181 005 "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Service and Capability 
Requirements", (note 1) 
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References in 3GPP TS 23.228 [1] 


Replaced references 


9 


3GPP TS 23.207: "End-to-end QoS concept and 
architecture". 


(note 2) 


10 


3GPP TS 24.228: "Signalling flows for the IP multimedia call 
control based on SIP and SDP". 


(note 2) 


10a 


3GPP TS 24.229: "IP Multimedia Call Control based on SIP 
and SDP; Stage 3". 


ETSI ES 283 003: " Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); IP Multimedia Call Control 
Protocol based on Session Initiation Protocol (SIP) 
and Session Description Protocol (SDP) Stage 3 
[3GPP TS 24.229 (Release 7), modified]", (note 1) 


11 


3GPP TS 25.301 : "Radio interface protocol architecture". 


(note 2) 


19 


3GPP TS 33.203: "Access Security for IP-based services". 


(note 2) 


21 


3GPP TS 26.235: "Packet Switched IVIultimedia Applications; 
Default Codecs". 


ETSI TR 181 005 "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Service and Capability 
Requirements", (note 1) 


23 


3GPP TS 23.060: "General Packet Radio Service (GPRS); 
Service description; Stage 2". 


(note 2) 


24 


3GPP TS 23.003: "Technical Specification Group Core 
Network; Numbering, addressing and identification". 


(note 2) 


25 


3GPP TS 32.240: "Telecommunication management; 
Charging management; Charging architecture and principles". 


ETSI ES 282 010: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Charging (Endorsement of 
3GPP TS 32.240 v6.3.0, 3GPP TS 32.260 v6.3.0, 
3GPP TS 32.297 v6.1 .0, 3GPP TS 32.298 v6.1 .0 and 
3GPP TS 32.299 v6.4.0 modified)", (note 1) 


26 


3GPP TS 32.260: "Telecommunication Management; 
Charging Management; IP Multimedia Subsystem (IMS) 
charging". 


ETSI ES 282 010: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Charging (Endorsement of 
3GPP TS 32.240 v6.3.0, 3GPP TS 32.260 v6.3.0, 
3GPP TS 32.297 v6.1 .0, 3GPP TS 32.298 v6.1 .0 and 
3GPP TS 32.299 v6.4.0 modified)", (note 1) 


27 


3GPP TS 22.071 : "Technical Specification Group Services 
and System Aspects, Location Services (LCS); Service 
description, Stage 1". 


(note 2) 


28 


3GPP TS 23.271 : "Technical Specification Group Services 
and System Aspects, Functional stage 2 description of LCS". 


(note 2) 


29 


3GPP TS 23.078: "Customised Applications for Mobile 
network Enhanced Logic (CAMEL) Phase 3 - Stage 2". 


(note 2) 


29a 


3GPP TS 22.340: "IMS Messaging; Stage 1". 


(note 2) 


30 


3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx 
Interfaces; Signalling flows and message contents". 


ETSI TS 183 033: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); IP Multimedia; Diameter based 
protocol for the interfaces between the Call Session 
Control Function and the User Profile Server 
Function/Subscription Locator Function; Signalling 
flows and protocol details [3GPP TS 29.228 V6.8.0 
and 3GPP TS 29.229 V6.6.0, modified]", (note 1) 


31 


3GPP TS 23.240: "3GPP Generic User Profile - Architecture; 
Stage 2". 


(note 2) 


32 


3GPP TS 22.250: "IP Multimedia Subsystem (IMS) group 
management; Stage 1". 


(note 2) 


36 


3GPP TS 23.141 : "Technical Specification Group Services 
and System Aspects, Presence Service". 


ETSI TS 182 008: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); Presence Service; Architecture 
and functional description (Endorsement of 3GPP 
TS 23.141 and OMA-AD-Presence SIMPLE-V1 0)". 
(note 1) 


37 


3GPP TS 26.141 :"IMS messaging and Presence; Media 
formats and codecs". 


(note 2) 


NOTE 1 : The reference in 3GPP TS 23.228 [1] is replaced by tlie document listed on the right column. This 
replacement is applicable to all occurrences of the reference throughout the present endorsement. 

NOTE 2: The reference in 3GPP TS 23.228 [1] contains 3GPP specific requirements and is not generally applicable to 
the present endorsement. 
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3.1 Definitions 

Add the following definition: 

Network Address Translation (NA(P)T): method by which IP addresses are mapped from one group to another, 
transparently to end users. Network Address Port Translation, or NA(P)T is a method by which many network 
addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a 
single network address and its TCP/UDP ports. See RFC 3022 [96] for further details 

Replace the definition of "ALG" as follows: 

Application Level Gateway (ALG): application specific functional entity that allows communication between 
disparate address realm or IP versions when certain applications carry network addresses in the payloads like SIP/SDP. 
NA(P)T-PT or NA(P)T is application unaware whereas ALGs are application specific translation entities that allow a 
host running an application to communicate transparently with another host running the same application but in a 
different IP version or IP address realm 

For IMS, an IMS ALG provides the necessary application function for SIP/SDP protocols in order to communicate 
between different address realms or IP versions. 

3.2 Symbols 
Add the following symbol. 

Gq' Reference Point between an IBCF and the SPDF 

3.3 Abbreviations 
Modify the following abbreviation: 

HSS Home Subscriber Server (Not relevant in NGN Release 1) 

Add the following abbreviations: 

IN Intelligent Network 

NAPT Network Address Port Translation 

NAT Network Address Translation 

NASS Network Attachment Subsystem 

RACS Resource and Admission Control Subsystem 

SPDF Service Policy Decision Function 

UPSF User Profile Server Function 

NP Number portability 

4.0 General 
Modify as shown below: 

- figure 4.0 is not endorsed 

4.1 Relationship to CS domain and the IP-Connectivity Access Network 

Modify the following sentence: 

The IP-CANs^ that maintains the service while the terminal moves ,-aHd hides these moves from the IP multimedia 
subsystem. 

4.2.1.1 Support for CAMEL 

Modify the title and the text as follows: 

- replace "CAMEL" with "CAMEL or IN" 

- replace "CSE" with "CSE or IN Service Environment" 
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4.6.1 Proxy-CSCF 

Add the following above the paragraph starting "The functions peformed by the P-CSCF" 

The Service Policy Decision Function (SPDF) may be a logical entity of the P-CSCF or a separate physical node. If the 
SPDF is implemented in a separate physical node, the interface between the SPDF and the P-CSCF is the Gq' interface 
standardised in TS 183 017 [981. 

Modify as shown below: 

If required for certain users, mM aintain a Security Association between itself and each UE, as defined in 
TS 33.203 [19]. 

Should p Performs SIP message compression/decompression depending on the resources provided by the 
access technology in use and local policy . 

Authorisation of bearer resources and QoS management. For details see TS 23.203 [54] and ES 282 003 [97] . 

NOTE 2: TS 23.203 [54] is not applicable when RACS is used. 

Add the following clause. 

4.18 Support of Number portability 

NOTE: The text of clause 4.18 is except for this note identical to the text of clause 4.18 of TS 23.228 
version 8.2.0. 

4.18.1 Number portability 

Number portability (NP) allows a user to retain their E. 164 number when changing subscriptions from one network 
operator to another. As such, NP applies to TEL URIs and SIP URI with user=phone parameters. NP is subject to 
regional requirements and is accomplished through the retrieval of ported data from those data bases. The specification 
of these data bases is out of scope of this document, but the NP data may be accessed through ENUM/DNS or accessed 
via existing (PSTN- and CS-domain) NP databases using the legacy PSTN/CS-domain protocols, such as TCAP. 

Support of NP within a network and the exact means to make the number portability data available to IMS, is subject to 
and configured per operator policy. NP is not mandated by this specification on any network operator. 

As configured per operator policy, IMS ENUM interfaces can be updated to support handling of the PSTN ENUM 
service per RFC 4769 [57], which provides a URI containing an E.164 number with NP routing information and NP dip 
indicators. The IMS entity receiving NP information as a result of an ENUM/DNS query, the S-CSCF as an example, 
needs to support, or not remove, NP protocol parameters retrieved as part of ENUM/DNS procedures contained in this 
specification. Subsequent network elements used to process the call to the PSTN do not remove the NP protocol 
parameters inserted in SIP messaging as part of the NP data retrieval procedure. 

NP data can also be made available by means of direct access to PSTN/CS-domain NP Databases using the legacy 
PSTN/CS-Domain interfaces and protocols. To support this existing interface within the network, the requesting and 
subsequent network elements need to support, or not remove, NP protocol parameters within SIP messages that result 
from the NP data retrieval procedures. The procedures to retrieve the NP data using the legacy PSTN/CS-domain 
interfaces are out of scope of this specification. 

Alternatively, per operator policy, the BGCF can retrieve NP data as part of the procedures to select an MGCF for 
PSTN connection. The interface used at the BGCF to retrieve the NP data is out of scope of this specification. 

Alternatively, per operator policy, the MGCF may support legacy interfaces to retrieve number portability data. 

NOTE: Although legacy protocols are used to access the number portability database, this does not imply that the 
IMS nodes (CSCFs, BGCFs) need to implement such protocols. 
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5.0 General 

Modify the text as follows: 

This section documents the main procedures that are used for the provision of services in the IP multimedia subsystem. 
These procedures are described using text description as well as information flow diagrams. The procedures described 
in this document are meant to provide a high level description and are not intended to be exhaustive. Additional 
procedures and details are provided in TS 21.228 [10] . 

5.2.2.5 Stored information 

Modify the text as follows: 

Table 5.1 provides an indication of some of the information stored in the indicated nodes during and after the 
registration process. Note that Table 5.1 is not an exhaustive list of stored information, i.e. there can be additional 
information stored due to registration. 

Table 5.1 : Information Storage before, during and after the registration process 



Node 


Before Registration 


During Registration 


After Registration 


UE - in local network 


Credentials 
Home Domain 
Proxy Name/Address 


Same as before 
registration 


Credentials 
Home Domain 
Proxy Name/Address 
UE P-GRUU 
At least one T-GRUU 


Proxy-CSCF 

- in Home or Visited 

network 


Routing Function 


Initial Network Entry point 

UE Address 

Public and Private User 

IDs 

And if the P-CSCF is 

located in a visited 

network: 


Final Network Entry point 

UE Address 

Public and Private User 

IDs 

And if the P-CSCF is 

located in a visited 

network: 


- IBCF in the visited 


- IBCF in the visited 


network address/name 


network address/name 


Interrogating-CSCF - in 
Home network 


HSS or SLF Address 


Serving-CSCF 
address/name 
P-CSCF Network ID 
Home Network contact 
Information 


No State Information 


HSS 


User Service Profile 


P-CSCF Network ID 


Serving-CSCF 
address/name\ 


Serving-CSCF (Home) 


No state information 


HSS Address/name 
User profile (limited - as 
per network scenario) 
Proxy address/name 
P-CSCF Network ID 
Public/Private User ID 
UE IP Address 
UE P-GRUU 


IVIay have session state 
Information 
Same as during 
registration 


UE T-GRUU 



5.4 



Procedures for IP Multi-media sessions 



5.4.2a IP version interworking concepts 

Modify as shown below: 

It should be possible for users connected to an IMS network to communicate with users that are connected to SIP based 
networks that use a different IP version via interworking or that are in a separate addressing range (e.g., NA(P)T 
functionality is set at the border of the IMS) . 
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5.4.4 Requirements for IP multi-media session control 

Modify as shown below: 

6. The solution shall comply with the architectural rules relating to separation of bearer level, session control 
level, and service level expressed in 23.221 [7] , 

5.4.5 Session Path Information 
Modify the text as follows: 

5.4.5.1 Session Path Information during Registration and Session Initiation 

During registration and session initiation there are SIP mechanisms, which provide the means to determine the session 
path. 

After registration the P-CSCF stores the S-CSCF name , possibly IBCF names and the S-CSCF stores the P-CSCF name 
and possibly IBCF names (see 4.3.4) as part of the UE related information. 

There is a need to store the session path that is determined during the session initiation request in order to route the 
subsequent session requests through this determined path. This is needed in order to route these session requests 
through certain nodes, e.g. the ones performing Service Control , or interconnect functions . CSCFs are assumed to 
perform certain actions: 

1 . CSCFs (Proxy and Serving) store a certain part of the session path determined during session initiation. This 
allows CSCFs to generate requests that traverse all elements on a Route path. 

2. The P-CSCF shall check correct usage of the header values. Should an UE build inaccurate header(s) in a SIP 
request, the P-CSCF may reject the request. If an operator policy requires enforcing the routes stored in P- 
CSCF, the P-CSCF shall overwrite the header(s) provided by the UE with the appropriate values. 

5.4.7 Interaction between QoS and session signalling 

Clauses 5.4.7.0 to 5.4.7.7 are not applicable to IP-CANs using RAGS. 

Add the following clause: 

5.4.7a Interaction between RAGS and IMS 

The P-CSCF interacts with the RACS in order to do the following: 

Request bindings data between the different IP addresses (NA(P)T or NA(P)T-PT) upon session 
initiation/modification. 

Request media latching in hosted NAT scenarios. 

Release the bindings at session release. 

Open/close gates between domains (i.e. packets filtering depending on "IP address / port"). 

Perform packet marking. 

Resource allocation and bandwidth reservation for upstream and downstream traffic. 

Policing of incoming traffic. 

More details can be found in ES 282 003 [97] and TS 183 017 [98]. 

5.6 Origination procedures 

Modify the text as follows: 
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5.6.1 (M0#1) Mobile origination, roaming 

This clause is endorsed with the clarification that "P-CSCF(PCRF)" is replaced by "P-CSCF". 

5.6.2 (M0#2) Mobile origination, home 

This clause is endorsed with the clarification that "P-CSCF(PCRF)" is replaced by "P-CSCF". 
Insert the following clause: 



5.6.2a 



(F0#1) Fixed origination, home 



This origination procedure applies to users located in their home service area. As in clause 5.6.2, the UE is located in 
the home network, but is using an xDSL IP-CAN to access the IMS Core. 

NOTE: The below flows are example flows. The detailed stage 2 description of the RACS information flows can 
be found in ES 282 003 [97]. 



Originating Home Networlc 



UE 



C-BGF 



1. INVITE (SDP offer) 



9. Offer Response 



10. Resp. Conf(OptSDPl 



RACS P-CSCF 



;. Reserve Connection 



8. Re source Admission & 
Connection Configuration 



21. Approval of QoS Commit 
&.Open Gates 



3. INVITE (SDP offer) 



7. Offer Response 



1 1. Resp. Conf (Opt SDP) 



S-CSCF 



4. Service Control 



5. INVITE (SDP offer) 



6. Offer Response 



12. Resp. Conf (Opt SDP) 



Figure 5.15a: Fixed xDSL originating - home (example flow) 
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Procedure F0#1 is as follows: 



1 . UE sends the SIP INVITE request, containing an initial SDP, to the P-CSCF address determined with P-CSCF 
discovery mechanism. The initial SDP may represent one or more media for a multi-media session. 

2. A connection is reserved in the C-BGF with optional NAT binding list retrieval. 

3. P-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. In this case it forwards 
the INVITE to the S-CSCF in the home network. 

4. S-CSCF validates the service profile, and invokes any origination service logic required for this user. This 
includes authorisation of the requested SDP based on the user's subscription for multi-media services. 

5. S-CSCF forwards the request, as specified by the S-S procedures. 

6. The media stream capabilities of the destination are returned along the signalling path, per the S-S procedures. 

7-9. S-CSCF forwards the Offer Response message to the P-CSCF which triggers RACS. RACS performs 
admission control based on the Offer and Answer parameters. 

RACS configures the connections in the C-BGF based on the SDP answer and optionally requests a NAT 
binding list. 

10. UE decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends 
the Response Confirmation to P-CSCF. The Response Confirmation may also contain SDP. This may be the 
same SDP as in the Offer Response received in Step 9 or a subset. If new media are defined by this SDP, a 
new connection configuration shall be performed following Step 2. The originating UE is free to continue to 
offer new media in this request or in subsequent requests using the Update method. Each offer/answer 
exchange will cause the P-CSCF to repeat the RACS interactions again. 

1 1 . P-CSCF forwards this message to S-CSCF 

12. S-CSCF forwards this message to the terminating endpoint, as per the S-S procedure. 

13. The terminating end point responds to the originating end with an acknowledgement. If Optional SDP is 
contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response. If 
the SDP has changed, the admission control and configure connection flows are repeated. 

14-15. S-CSCF and P-CSCF forward the answered media towards the UE. 

16-18. The destination UE may optionally perform alerting. If so, it signals this to the originating party by a 

provisional response indicating Ringing. This message is sent to S-CSCF per the S-S procedure. It is sent from 
there toward the originating end along the signalling path. UE indicates to the originating user that the 
destination is ringing. 

19-20. When the destination party answers, the terminating endpoint sends a SIP 200-OK final response along the 
signalling path to the originating endpoint, as specified by the termination procedures and the S-S procedures. 

21 . P-CSCF performs the approval of QoS Commit procedure which triggers the Open Gates procedures if 
required. 

22. P-CSCF passes the 200-OK response back to UE 

23. UE starts the media flow(s) for this session. 

24-26. UE responds to the 200 OK with an ACK message which is sent to P-CSCF and passed along the signalling 
path to the terminating endpoint. 

Insert the following clause: 
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5.7.2b 



(FT#1) Fixed termination, home 



NOTE: The below flows are example flows. The detailed stage 2 description of the RACS information flows can 
be found in ES 282 003 [97]. 

This termination procedure applies to users located in their home service area. As in clause 5.7.2, the UE is located in 
the home network, but has registered to the IMS Core via an xDSL IP-CAN. 
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Figure 5.18b: Fixed xDSL terminating - home (example flow) 

Procedure FT#1 is as follows: 

1. UE#1 sends the SIP INVITE request, containing an initial SDP, via one of the origination procedures and the 
S-S procedures, to the Serving-CSCF for the terminating UE. 

2. S-CSCF validates the service profile, and invokes any termination service logic required. This includes 
authorisation of the requested SDP based on the user's subscription for multi-media services. 

3. S-CSCF remembers (from the registration procedure) the P-CSCF address for this UE. The S-CSCF forwards 
the INVITE to the P-CSCF, which in this case is located in the home network. 

4. The P-CSCF triggers RACS which reserves a connection in C-BGF with optional NAT binding retrieval. 

5. P-CSCF remembers (from the registration procedure) the UE address, and forwards the INVITE to the UE. 
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6. UE determines the subset of the media flows proposed by the originating endpoint that it is capable and willing 
to support, and responds with an Offer Response message back to the originator. The SDP may represent one 
or more media for a multi-media session. This response is sent to the P-CSCF. 

7. P-CSCF triggers RACS to perform admission control based on Offer and Answer parameters. 

RACS configures the connection in the C-BGF based on SDP answer with optional NAT binding retrieval. 

8. P-CSCF forwards the Offer Response message to S-CSCF. 

9. S-CSCF forwards the Offer Response message to the originator, per the S-S procedure. 

10-15. The originating endpoint sends a Response Confirmation via the S-S procedure, to the terminating S-CSCF. 
The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response sent 
in Step 19 or a subset. If new media are defined by this SDP, a new interaction with the RACS (as in Step 4-8) 
will be done by the P-CSCF. The originating UE is free to continue to offer new media in this request or in a 
subsequent request using the Update method. Each offer/answer exchange will cause the P-CSCF to repeat the 
RACS interactions (Step 4-8) again. 

16-18. UE may alert the user and wait for an indication from the user before completing the session. If so, it 

indicates this to the originating party by a provisional response indicating Ringing. This message is sent to 
P-CSCF and along the signalling path to the originating endpoint. 

19. When the destination party answers, UE sends a SIP 200-OK final response to P-CSCF. 

20. P-CSCF indicates that the resources reserved for this session should now be committed. 

21-22. P-CSCF forwards the 200-OK to S-CSCF, following the signalling path. 

23-25. The session originator responds to the 200-OK by sending the ACK message to S-CSCF via the S-S 
procedure and it is forwarded to the terminating end along the signalling path. 

Annex G (Normative): Reference Architecture and procedures winen tine NAT is invoked between tine UE and 
tine IMS domain 

Modify as follows: 

G.2 Reference model 

The requirements in this clause do not apply when RACS is used. 

Add the following clause: 

G.2A Reference model with RAGS 

Figure G.la presents the general reference model for IMS access when both the signalling and media traverses NAT 
devices. Figure G.2a presents the general reference model when IP address translation is needed between the IP-CAN 
and the IMS domain. The IMS network architecture is the same for both cases. 

NOTE: The P-CSCF and the C-BGF may belong to different operators. 
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Figure G.I a: Reference model for IMS access where UE is located behind a hosted NAT 



Signailing path 
Bearer path 




G.3 



Figure G.2a: Reference model for IMS access with IP address conversion in the media path 

Network elements for employing the IMS-ALG and IMS Access Gateway 



G.3.1 Required functions of the P-GSGF 

The requirements in this clause do not apply when RACS is used. 
Add the following clause: 



G.3.1A 



Required functions of the P-GSGF with RAGS 



For performing communication with UEs when IP address translation is needed between the IP-CAN and the IMS 
domain on the media path only (Figure G.2a) or on both the media and signalling (Figure G.la), the P-CSCF shall 
perform the following functions: 

Act as an IMS-ALG by changing the appropriate SIP/SDP parameters in order to translate addresses into same 
or different IP version addresses, in case NA(P)T or NA(P)T-(PT) is required between the IP-CAN domain 
and the IM Subsystem core network elements. 

Request the RACS to provide the IP address bindings data upon session initiation, to modify those bindings 
any time during the session, and to release the bindings at session release. 
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Additionally in support of the hosted NAT scenarios (see Figure G.l), the P-CSCF shall request the RACS to initiate 
media latching, in order to retrieve the remote address information of the media received from, and sent to, a NAT 
device between the P-CSCF and the served UE. 

G.3.2 Required functions of tine IMS Access Gateway 

The requirements in this clause do not apply when RACS is used. 

G.3.3 Iq reference point 

The requirements in this clause do not apply when RACS is used. 

Add the following clause: 

G.4.2a NAT traversal for signalling 

To keep the NAT binding and firewall pinholes open for signalling traffic, one of the following methods shall apply: 

• A registration timer shall be provisioned in the P-CSCF for the TEs behind a NAT or firewall. To minimize the 
number of SIP Register messages between the P-CSCF and the S-CSCF, the P-CSCF may forward the 
minimum number of SIP Register messages required by the S-CSCF registration timer. This method is 
controlled by the P-CSCF, and has the benefit to be transparent to the TE. 

• An Outbound [48] keep alive for NAT binding may be sent by the TE to the SIP port of the P-CSCF using the 
same transport address information (source and destination) which was used for the registration request. This 
method is controlled by the TE. It may be complementary to the first one in case the P-CSCF does not 
provision the appropriate registration timer for the TE. 

G.4.3 Session establishment procedure 

The requirements in this clause do not apply when RACS is used. 

G.4.4 Session release procedure 

The requirements in this clause do not apply when RACS is used. 

G.4.5 Session modification 

The requirements in this clause do not apply when RACS is used. 

G.4.6 Media forwarding in the IMS Access Gateway 

The requirements in this clause do not apply when RACS is used. 

G.5 Network elements for employing NAT Traversal for ICE and Outbound 

The requirements in this clause do not apply when RACS is used. 

G.6 Procedures for employing ICE and Outbound 

The requirements in this clause do not apply when RACS is used. 

Annex I (normative): Border Control Functions 

Modify as follows: 

Replace clause 1.2 with the following: 
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1.2 



Overall architecture 



Figure 1.2.1 presents a high-level architecture diagram showing how Border Control Functions fit into the IMS 
architecture. 
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Figure 1.1 : Border Control Functions 

The Mx reference point allows S-CSCF/1-CSCF/P-CSCF to communicate with an IBCF in order to provide border 
control functions. 

1.3.1 .1 Originating Session Flows towards IPv4 SIP network 

This clause is endorsed with the clarification that the TrGW is replaced by the I-BGF when the RACS is used. 

1.3.1 .2 Terminating Session Flows from IPv4 SIP network 

This clause is endorsed with the clarification that the TrGW is replaced by the I-BGF when the RACS is used. 
Add the following clause: 

1.3. 2A Additional IBCF screening functions 

The IBCF can filter all SIP signalling information based on source/destination and operator policy (e.g. remove 
information that is of local significance to an operator). 



Add the following clause: 



I.3.2B 



Addition of the IWF 



The IBCF can detect whether an IWF needs to be added in the SIP signalling path. The IBCF can insert the IWF in the 
signalling route when appropriate. 
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Annex ZA (normative): 
IP version considerations 



The present document does not place any requirement with regards to the IP version to be supported by UEs for 
accessing the IMS Core. More specifically the following scenarios are supported: 

IP version 4 only UEs accessing the IMS Core. 

IP version 6 only UEs accessing the IMS Core. 

Dual stack UEs accessing the IMS Core. 

The IP version used by IMS Core entities (e.g. CSCFs) to exchange SIP signalling depends on the IP version used by 
the terminals that a given operator is willing to support. A number of scenarios are hence possible. 

NOTE: An analysis of the requirements deriving for each of those scenarios in a GPRS environment can be found 
in 3GPPTR 23.981 [99]. 
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Annex ZB (normative): 
Interaction with the RACS 

ZB.1 IBCF interaction with the RACS 

The IBCF may interact with the RACS in order to do the following: 

Provide the RACS with information on the "resource reservation service class" required for a particular 
session; the "resource reservation service class" enables the RACS to derive transport layer characteristics 
required for a session (e.g. decision to include an I-BGF for the session, or media interconnect link selection 

etc.). 

Request bindings data between the different IP addresses (NA(P)T or NA(P)T-PT) upon session 
initiation/modification. 

Release the bindings at session release. 

Open/close gates between domains (i.e. packets filtering depending on "IP address / port"). 

Perform packet marking. 

Resource allocation and bandwidth reservation for upstream and downstream traffic. 

Policing of incoming traffic. 

The above functions may or may not instantiated by the IBCF depending on local policy and incoming signalling 
information. Additionally, the IBCF may decide, in some cases, based on the SIP signalling and operator-specific 
policy, not to contact the RACS. 
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